Web 应用程序验证机制有哪些设计缺陷

与Web应用程序常用的任何其他安全机制相比，验证功能中存在着更多设计方面的薄弱环节。即使在基于用户名和密码验证用户这种非常简单的标准化模型中，其中包含的设计缺陷也容易导致应用程序被非法访问。常见设置缺陷有以下这些。

密码保密性不强

- 非常短或空白的密码；
- 以常用的字典词汇或名称为密码；
- 密码和用户名完全相同；
- 仍然使用默认密码。

蛮力攻击登录

登录功能的公开性往往诱使攻击者试图猜测用户名和密码，从而获得未授权访问应用程序的权力。如果应用程序允许攻击者使用不同的密码重复进行登录尝试，直到找到正确的密码，那么它就非常容易遭受攻击，因为即使是业余攻击者也可以在浏览器中手动输入一些常见的用户名和密码。

详细的失败消息

一个典型的登录表单要求用户输入两组信息（用户名和密码），而另外一些应用程序则需要更多信息（如出生日期、纪念地或PIN号码）。如果登录尝试失败，当然可以得出结论：至少有一组信息出错。但是，如果应用程序通知是哪一组信息无效，就可以利用它显著降低登录机制的防御效能。在最简单的情况下，如果只需要用户名和密码登录，应用程序可能会通过指出失败的原因（用户名无效或密码错误）来响应失败的登录尝试。

在这种情况下，攻击者可以发动一次自动化攻击，遍历大量常见的用户名，确定哪些有效。当然，用户名一般并非秘密（例如，登录时并不隐藏用户名）。但是，如果攻击者能够轻易确定有效的用户名，就更可能在有限的时间内、运用一定的技能、付出一定的精力攻破应用程序，并将枚举出的用户名列表作为随后各种攻击的基础，包括密码猜测、攻击用户数据或会话，或者社会工程。除主要的登录功能外，还可以对验证机制的其他组件进行用户名枚举。

证书传输易受攻击

如果应用程序使用非加密的HTTP连接传输登录证书，处于网络适当位置的窃听者当然就能够拦截这些证书。即使是通过HTTPS登录，如果应用程序处理证书的方式并不安全，证书仍有可能被泄露给未授权方。许多应用程序对应用程序中未经验证的区域使用HTTP，而在登录时转而使用HTTPS。如果是这样，应在向浏览器加载登录页面时转换到HTTPS，使得用户能够在输入证书前核实页面是否真实可信。但是，一些应用程序通常使用HTTP加载登录页面，而在提交证书时才转换到HTTPS。这样做是不安全的，因为用户不能核实登录页面的真实性，因此无法保证安全提交证书。那么，处在适当位置的攻击者就可以拦截并修改登录页面，更改登录表单的目标URL以使用HTTP。等到精明的用户意识到证书已使用HTTP提交时，攻击者已成功获取这些证书。

忘记密码功能

与密码修改功能一样，重新获得忘记密码的机制常常会引入已在主要登录功能中避免的问题，如用户名枚举。除这种缺陷外，忘记密码功能设计方面的缺点往往使它成为应用程序总体验证逻辑中最薄弱的环节。

“记住我”功能

为方便用户，避免他们每次在一台特定的计算机上使用应用程序时需要重复输入用户名和密码，应用程序通常执行“记住我”功能。这些功能在设计上并不安全，致使用户易于遭受本地和其他计算机用户的攻击。

用户伪装功能

一些应用程序允许特权用户伪装成其他用户，以在该用户的权限下访问数据和执行操作。例如，一些银行应用程序允许服务台操作员口头验证一名电话用户，然后将银行的应用程序会话转换到该用户的权限下，以为其提供帮助。

可预测的用户名

一些应用程序根据某种可以预测的顺序（如cust5331、cust5332）自动生成账户用户名。如果应用程序以这种方式运转，弄清了用户名顺序的攻击者就可以很快获得全部有效用户名，以此作为后续攻击的基础。与依赖不断提交由词汇驱动请求的枚举方法不同，这种确定用户名的方法不需实施入侵，也很少给应用程序造成干扰。